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DETAILED ACTION 

Response to Amendment 

1 . This office action is in response to the Applicants' Amendment After Final filed on 
November 20, 2008. Claims 8, 10-15, and 17-18 are presented for further consideration 
and examination. 

2. Applicants' request for reconsideration of the finality of the rejection of the last Office 
action is persuasive and, therefore, the finality of that action is withdrawn. 

3. In view of the Amendment After Final filed on November 20, 2008, PROSECUTION IS 
HEREBY REOPENED. New grounds of rejection are set forth below. 

Response to Argument 

4. Applicants' arguments, see pg.2-4, filed on November 20, 2008, with respect to claims 8 
and 14 have been fully considered and are persuasive. The previous rejection is 
withdrawn. New grounds of rejection are set forth below. 
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Claim Rejections - 35 USC §103 


5. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 


6. Claims 8, 10-15, and 17-18 are rejected under 35 U.S.C. 103(a) as being unpatentable 
overDutta etal. (US006615212B1), in view of Meltzer et al. (US006226675B1), and in 
view of Low et al. (US00521 8605), 


7. With regard to claims 8, and 14, Dutta discloses, 

• a subscriber interface for adapting to subscriber computers that are connected to 
the gateway device to facilitate communications between the subscriber 
computers and at least one network; and (Dutta, col.1, line 8 - col. 16, line 17) 
Dutta discloses, "Turning now to FIGS. 6 and 7, there are shown block diagrams 
illustrating the data flow through a prior art transcoding proxy server. In FIG. 6, 
client 602 sends HTTP request 604 to transcoding proxy server 606. 
Transcoding proxy server 606 includes transcoding framework 608 for converting 
requests in one format to requests in a second format. Transcoding framework 
608 includes HTTP request transform plugin 610 for converting HTTP request 
604 received from client 602 into a modified HTTP request 612 compatible with 
originating server 614, where the requested content is located. As shown in FIG. 
7, transcoding proxy server 606 receives server response 702 in Extensible 
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Markup Language (XML) data format. Transcoding framework 608 also includes 
XML to HTML transcoder plugin 704. XML to HTML transcoder plugin 704 
converts server response 702 from XML data format to an HTML data format and 
sends HTML data 706 to client 602 for processing" (Dutta, col.7, lines 45-62). 
Hence, Dutta teaches of the transcoder framework 608 (i.e., Applicants' 
subscriber interface) located on the transcoding proxy server 606 (i.e., 
Applicants' gateway device) converting requests in one format to requests in a 
second format (i.e., Applicants' adapting to subscriber computers) and sending 
(i.e., Applicants' facilitating communications between) HTML data 706 to client 
602 (i.e., Applicants' subscriber computers) from originating server 614 on a 
network (i.e., Applicants' at least one network). 

• an XML interface comprising a parser front end, a parser section responsive to 
the parser front end and a building section for communicating with an external 
device via a series of XML commands and responses such that the gateway 
device, located at a network access point, supports communications involving the 
subscriber computers and the external devices without requiring the subscriber 
computers to support XML commands and responses, wherein said parser front 
end determines the type of operation requested by the external device; and 
(Dutta, col.1, line 8 - col. 16, line 17) 

Dutta discloses, "Turning now to FIGS. 6 and 7, there are shown block diagrams 
illustrating the data flow through a prior art transcoding proxy server. In FIG. 6, 
client 602 sends HTTP request 604 to transcoding proxy server 606. 
Transcoding proxy server 606 includes transcoding framework 608 for converting 
requests in one format to requests in a second format. Transcoding framework 
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608 includes HTTP request transform plugin 610 for converting HTTP request 
604 received from client 602 into a modified HTTP request 612 compatible with 
originating server 614, where the requested content is located. As shown in FIG. 
7, transcoding proxy server 606 receives server response 702 in Extensible 
Markup Language (XML) data format. Transcoding framework 608 also includes 
XML to HTML transcoder plugin 704. XML to HTML transcoder plugin 704 
converts server response 702 from XML data format to an HTML data format and 
sends HTML data 706 to client 602 for processing" (Dutta, col.7, lines 45-62). 
Hence, Dutta teaches of the transcoder plugin 704 (i.e., Applicants' XML 
interface) located on the transcoding proxy server 606 (i.e., Applicants' gateway 
device located at a network access point) receiving (i.e., Applicants' 
communicating) responses from the originating server 614 (i.e., Applicants' 
external device), converting server responses 702 from XML data format to an 
HTML data format (i.e., Applicants' via a series of XML commands and 
responses), and sending (i.e., Applicants' supporting communications) the 
resulting HTML data 706 to client 602 (i.e., Applicants' subscriber computers) 
from originating server 614 (i.e., Applicants' external device). Since, the 
responses from originating server 614 already converted to HTML format by the 
transcoding proxy server, the client 602 (i.e., Applicants' subscriber computer) 
does not need to support XML (i.e., Applicants' without requiring the subscriber 
computers to support XML commands and responses). 

• an internal web server for communicating with both said XML interface and the 
Internet to thereby facilitate XML-based communications between the gateway 
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device and external devices connected to the Internet. (Dutta, col.1, line 8 - 
col. 16, line 17) 

Dutta discloses, "Turning now to FIGS. 6 and 7, there are shown block diagrams 
illustrating the data flow through a prior art transcoding proxy server. In FIG. 6, 
client 602 sends HTTP request 604 to transcoding proxy server 606. 
Transcoding proxy server 606 includes transcoding framework 608 for converting 
requests in one format to requests in a second format. Transcoding framework 
608 includes HTTP request transform plugin 610 for converting HTTP request 
604 received from client 602 into a modified HTTP request 612 compatible with 
originating server 614, where the requested content is located. As shown in FIG. 
7, transcoding proxy server 606 receives server response 702 in Extensible 
Markup Language (XML) data format. Transcoding framework 608 also includes 
XML to HTML transcoder plugin 704. XML to HTML transcoder plugin 704 
converts server response 702 from XML data format to an HTML data format and 
sends HTML data 706 to client 602 for processing" (Dutta, col.7, lines 45-62). 
Hence, Dutta teaches of the transcoder framework 608 (i.e., Applicants' XML 
interface) located on the transcoding proxy server 606 (i.e., Applicants' internal 
web server) converting requests in one format to requests in a second format 
and sending HTML data 706 (i.e., Applicants' facilitate XML-based 
communications) to client 602 (i.e., Applicants' external devices) from originating 
server 614 on a network (i.e., Applicants' at least one network). 

However, Dutta does not explicitly disclose, 

• an XML interface comprising a parser front end, a parser section responsive to 
the parser front end and a building section for communicating with an external 
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device via a series of XML commands and responses such that the gateway 
device, located at a network access point, supports communications involving the 
subscriber computers and the external devices without requiring the subscriber 
computers to support XML commands and responses, wherein said parser front 
end determines the type of operation requested by the external device; and 
Meltzer teaches, 

• an XML interface comprising a parser front end, a parser section responsive to 
the parser front end and a building section for communicating with an external 
device via a series of XML commands and responses such that the gateway 
device, located at a network access point, supports communications involving the 
subscriber computers and the external devices without requiring the subscriber 
computers to support XML commands and responses, wherein said parser front 
end determines the type of operation requested by the external device; and 
(Meltzer, col.1 , line 7 - col. 86, line 42) 

Meltzer discloses, "A node in the commerce network establishes an interface for 
transactions according to the present invention that comprises a machine- 
readable specification of an interface, along with a machine-readable data 
structure that includes interpretation information for the machine-readable 
specification of the interface. The machine-readable specification of the interface 
includes a definition of an input document and a definition of an output document, 
that are accepted and produced by transaction processes for which the node 
acts as an interface. The definitions of the input and output documents comprise 
respective descriptions of sets of storage units and logical structures for sets of 
storage units, such as according to a standard XML based document. The 
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machine-readable data structure that includes interpretation information 
according to various aspects of the invention includes data type specifications 
(e.g. string, array, etc.) for logical structures in the definitions of the input and 
output documents, content models (e.g. lists of possible values) for logical 
structures and/or data structures that map predefined sets of storage units for a 
particular logic structure to respective entries in a list in order to provide a 
semantic definition of logical structures (e.g. mapping codes to product names)" 
(Meltzer, col.3, line 55 - col.4, line 10). Hence, Meltzer teaches of interpreting 
and translating information between documents with respect to data type 
specifications, content models, and data structures (i.e., Applicants' via a series 
of XML commands and responses). 

Therefore, it would have been obvious to one of ordinary skill in the art at the time of 
the invention was made to combine the teaching of Meltzer with the teaching of Dutta 
to "[facilitate] interaction amongst diverse platforms in a communication network. 
Such system should facilitate spontaneous commerce between trading partners 
without custom integration or prior agreement on industry wide standards. Further, 
such systems should encourage incremental path to business automation, to 
eliminate much of the time, cost and risks of traditional systems integration" (Meltzer, 
col.2, lines 18-25). Dutta discloses, "However, much of the information now 
available on the Web are legacy files created before the proliferation of the Internet 
and the Web. These files are often very large and were not created with the thought 
that they might someday be transmitted back and forth across the Internet. These 
files can take a very long time to transmit over the Web, and it can also take a very 
long time to transcode their contents into a different data format. Therefore, there is a 
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need for an improved method of transcoding data formats and sending information 
across the web to minimize transmission times" (Dutta, col.2, lines 26-35). 

However, Dutta and Meltzer do not explicitly disclose, 

• an XML interface comprising a parser front end, a parser section responsive to 
the parser front end and a building section for communicating with an external 
device via a series of XML commands and responses such that the gateway 
device, located at a network access point, supports communications involving the 
subscriber computers and the external devices without requiring the subscriber 
computers to support XML commands and responses, wherein said parser front 
end determines the type of operation requested by the external device; and 

Low teaches, 

• an XML interface comprising a parser front end, a parser section responsive to 
the parser front end and a building section for communicating with an external 
device via a series of XML commands and responses such that the gateway 
device, located at a network access point, supports communications involving the 
subscriber computers and the external devices without requiring the subscriber 
computers to support XML commands and responses, wherein said parser front 
end determines the type of operation requested by the external device; and (Low, 
col.1, line 5 -col. 18, line 12) 

Low discloses, "FIG. 9 shows a detailed representation of a preferred 
embodiment of the symbol interpreter module 314. A front parser module 902 
receives the composite data from the pipe module 310, and distributes this 
composite data to "CHK" modules (904, 910, 914), to determine the type of 
composite data received." (Low, col. 15, lines 5-10). Low discloses, "A CHK.sub.- 
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- cmd sub-module 910 checks the composite data received by the symbol 
interpreter module 314 to see if the composite data is an RD/RT command. If 
the CHK.sub.- cmd sub-module 910 determines that a command has been 
received, it sends the command to a CMD. sub.- parser sub-module 912, 

which verifies that a correct command was, in fact, received. The CMD. sub. - 

parser sub-module 912 then sends the command to the appropriate sub-module 
in the command processor module 316 for processing" (Low, col. 15, lines 23-32). 
Hence, Low teaches of a front parser (i.e., Applicants' parser front end) 
determining (i.e., Applicants' determine) the type of composite data which 
includes determining the command (i.e., Applicants' type of operation) requested. 

Therefore, it would have been obvious to one of ordinary skill in the art at the time of 
the invention was made to combine the teaching of Low with the teaching of Dutta 
and Meltzer to "[facilitate] interaction amongst diverse platforms in a communication 
network. Such system should facilitate spontaneous commerce between trading 
partners without custom integration or prior agreement on industry wide standards. 
Further, such systems should encourage incremental path to business automation, 
to eliminate much of the time, cost and risks of traditional systems integration" 
(Meltzer, col.2, lines 18-25). Dutta discloses, "However, much of the information now 
available on the Web are legacy files created before the proliferation of the Internet 
and the Web. These files are often very large and were not created with the thought 
that they might someday be transmitted back and forth across the Internet. These 
files can take a very long time to transmit over the Web, and it can also take a very 
long time to transcode their contents into a different data format. Therefore, there is a 
need for an improved method of transcoding data formats and sending information 
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across the web to minimize transmission times" (Dutta, col.2, lines 26-35). Low 
discloses, "Once the CHK.sub.- key sub-module 914 has determined that the 
composite data sent to the symbol interpreter module 314 is input data, it then 
determines which input device 110 the data has been sent by, and directs the 
composite data to one of three sub-modules (916, 918, 920), which translate the 
composite data into a format recognizable by the remote device 108" (Low, col.1 5, 
lines 37-44). 


8. With regard to claims 10-11 and 17-18, Dutta, Meltzer, and Low disclose, 

• wherein said parser section organizes elements parsed from at least one of an 
XML command and an XML response into separate XML parameters and passes 
at least some of the organized elements to a requested application. (Dutta, col.1 , 
line 8 -col. 16, line 17; Meltzer, col.1, line 7 - col.86, line 42; col.21, lines 47-52, 
lines 60-64; col.23, lines 46-53; module 304 on sheet 3, fig. 3; module 404 on 
sheet 4, fig. 4; Low, col.1, line 5 - col. 18, line 1). 

• wherein said parser section also nests the elements to be passed to the 
requested application within an application programming interface (API) wrapper. 
(Dutta, col.1, line 8 -col. 16, line 17; Meltzer, col.1, line 7 - col.86, line 42; col.25, 
line 66 - col. 26, line 8; module 515 on sheet 5, fig. 5; Low, col.1, line 5 - col. 18, 
line 1). 


9. With regard to claims 12-13 , Dutta, Meltzer, and Low disclose, 

• wherein said building section prepares responses to requests received by the 
gateway device. (Dutta, col.1, line 8 - col. 16, line 17; Meltzer, col.1, line 7 - 
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col.86, line 42; col.23, lines 23-28, lines 53-60; modules 406-407 on sheet 4, 
fig.4; Low, col.1, line 5 - col. 18, line 1). 
• wherein said building section assembles results returned by a requested 

application into an XML response. (Dutta, col.1, line 8 - col. 16, line 17; Meltzer, 
col.1, line 7 - col.86, line 42; col.23, lines 23-28, lines 53-60; modules 406-407 
on sheet 4, fig.4; Low, col.1, line 5 - col.1 8, line 1). 


10. With regard to claim 15 , Dutta, Meltzer, and Low disclose, 

• wherein receiving an XML command comprises receiving an XML command at 
the gateway device from a billing and content server (Dutta, col.1 , line 8 - col.1 6, 
line 1 7; Meltzer, col.1 , line 7 - col.86, line 42; col.21 , line 64 - col.22, line 2; 
modules 305-307 on sheet 3, fig. 3; Low, col.1, line 5 - col. 18, line 1). 


Response to Arguments 

1 1 . Applicants' arguments with respect to claims 8 and 14 have been considered but are 
moot in view of the new ground(s) of rejection. 

Conclusion 

12. Any inquiry concerning this communication or earlier communications from the examiner 
should be directed to Thomas Duong whose telephone number is 571/272-391 1 . The 
examiner can normally be reached on M-F 7:30AM - 4:00PM. If attempts to reach the 
examiner by telephone are unsuccessful, the examiner's supervisor, Jason D. Cardone 
can be reached on 571/272-3933. The fax phone numbers for the organization where 
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this application or proceeding is assigned are 571/273-8300 for regular communications 
and 571/273-8300 for After Final communications. 


/Patrice Winder/ 

Primary Examiner, Art Unit 2445 


/Thomas Duong/ 

Patent Examiner, Art Unit 2445 

November 26, 2008 


